Described below are methods and devices for setting up a telecommunications connection.
Alongside the so-called ‘Circuit-Switched (CS) domain’ of a mobile communications network based on the 3rd Generation Partnership Project (3GPP), the so-called ‘IP Multimedia Subsystem’ (IMS) can also be utilized for voice and video telephony, and a so-called ‘Interworking’ of the relevant services, i.e. connecting of the services by a suitable conversion of the signaling used and the transport format used for the data, between the IMS and the CS domain, is required. The IMS is also used, alongside the 3GPP Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS) access networks, for other access networks, for example the Wireless Local Area Network (WLAN) and Digital Subscriber Line (DSL). Precisely in these scenarios, it can initially be anticipated that voice and video telephony are effected by way of the IMS. Video telephony can also be utilized in a public telephone network, i.e. a so-called ‘Public Switched Telephone Network (PSTN)’, with the same inband video telephony specific protocols as in the 3GPP CS domain being utilized for transport and signaling in this instance as a rule. An interworking with respect to the IMS is also required from the PSTN.
Up to now, just an interworking between the IMS and the CS domain or the PSTN, and only for voice telephony, has been described in the standard. The method described below relates to the corresponding interworking of video telephony. A demand for this can be foreseen since video telephony is gaining in importance both in the 3GPP CS domain and also in the IMS, in this instance particularly for access networks such as WLAN or DSL, or newly arising network access options (e.g. Worldwide Interoperability for Microwave Access (WiMAX)).
The interworking between the IMS and a CS network, that is to say a PSTN or a 3GPP CS domain, is specified, as from 3GPP Release 6, only for pure voice telephony in 3GPP TS 29.163.
As defined by TS 29.163, the interworking of the so-called ‘call control’ signaling is effected in the so-called ‘Media Gateway Control Function’ (MGCF). The interworking of the payload connection, that is to say the passing on and repacking and also where necessary the transcoding of the payload data, is effected in the so-called ‘Internet Multimedia-Media Gateway’ (IM-MGW). The MGCF controls the IM-MGW by using the H.248 protocol standardized by the ITU-T, by way of the so-called ‘Mn’ interface, as is described further in 3GPP TS 29.332.
In the CS network, Bearer Independent Call Control (BICC) or ISDN User Part (ISUP) is used for call control signaling. In this case, if the call control signaling is routed separately from the transport connections, this method is also designated as ‘out-of-band’ signaling. As a further consequence, the possibility also exists of exchanging signaling messages within the transport connection, which messages are designated as ‘in-band’ signaling operations. In the case of ISUP, Time Division Multiplex (TDM) is utilized as the transport in the CS network and in the case of BICC, packet transport by using Internet Protocol (IP) or Asynchronous Transfer Mode (ATM). The negotiation as to whether pure voice telephony or video telephony is used can be effected for ISUP during the call control signaling for setting up the call, by using the so-called ISUP ‘UDI Fallback’ procedure. For BICC, this negotiation can be effected by using the ‘Service Change and UDI Fallback’ (SCUDIF) standardized in 3GPP TS 23.172, which enables a switch between voice telephony and video telephony even during the call. Both ‘UDI Fallback’ and SCUDIF utilize out-of-band signaling. Alongside this, it is possible for ISUP and also BICC not to use the aforesaid procedures, and to attempt a call setup only for video telephony, and in the case that video telephony is not supported, to terminate the call setup. In contrast to the optional negotiation between voice and video, the negotiation of the voice and video codecs used for video telephony is effected in-band, after video telephony has already been selected previously and a corresponding transport connection (‘bearer’) has been set up. For video telephony, a so-called ‘BS30’ data connection with 64 kbyte/s bandwidth is used in the CS network. Within this data connection, the H.324 protocol suite standardized by the ITU-T is used, the variant H.324M adapted for mobile communication being selected in the 3GPP CS domain. In this respect, following the setup of the data connection, the configuration of the multimedia connection is negotiated inband by way of the H.245 protocol standardized by the ITU-T, particularly the video codec and voice codec used and the details of the respective codec configuration. Voice and video are multiplexed within the same transport connection by using the H.223 protocol. For the 3GPP CS domain, TS 26.110 describes the use of the H.245 protocol suite in further detail, the so-called ‘H.324M’ configuration in particular being selected.
The main sequences during the setting up of a 3G-324M connection (‘session’) are as follows:    1. Following the beginning of the ISUP or BICC call setup signaling, the reservation of the necessary resources that are needed for the desired bearer is effected, and as a further consequence, the setup of the transport connection.    2. Beginning of the in-band negotiation. First, negotiation as to which H.223 multiplexer level is to be used for this transport connection.    3. Detection of the leading terminal which opens the multistream connection by using H.245 negotiation, if necessary. This function is only necessary if a conflict arises in the context of the opening of a bidirectional logical channel. This function is designated as ‘Master or Slave Determination’ (MSD).    4. By using so-called ‘Terminal Capability Set’ H.245 messages, the capabilities of the terminal sending the message are transmitted. Such messages are sent independently by both terminals. These described capabilities encompass the following information: audio and video codecs and their specific properties or their forms respectively, functional scope of the multiplexer, which adaptation layer is supported in detail (e.g. ‘simple’ or ‘nested’ multiplexing), and its mobile specific enhancements.    5. Setup of ‘logical’ channels for each media stream by using H.245 signaling. As from this point in time, either with or without MSD, the terminal or the IM-MGW is ready to open logical channels in order to enable the exchange of voice and/or video payload data. During the creation of a bidirectional logical channel, the channel number and the definitive media capabilities to be used are defined.    6. Definition of the multiplexing properties by using H.245.    7. Beginning of the transfer of video, audio/voice or data.
In the IMS, the negotiation for video telephony is effected out-of-band with the aid of the so-called ‘Session Description Protocol’ (SDP), IETF RFC 2327, which is transported by using the so-called ‘Session Initiation Protocol’ (SIP), IETF RFC 3261. In this respect, the negotiation as to whether voice telephony or video telephony is used is connected with the negotiation of the codecs used, and is effected before or during the setup of the bearers. The so-called SDP ‘offer-answer’ mechanism as defined by RFC 3264 is used. In this respect, the offering party sends a list of supported codecs in the SDP ‘offer’ message. Following receipt of this message, the answering party sends an SDP ‘answer’ message that contains those codecs from the list that it also supports and wishes to use. The answering party must not specify any codecs that were not contained in the list in the SDP ‘offer’. In contrast to the CS domain, two separate transport connections (bearers) are utilized for voice and video, which use the so-called ‘Real Time Transport Protocol’ (RTP), IETF RFC 3550 in each case. For the 3GPP IMS by way of the General Packet Radio Service (GPRS) access network, 3GPP TS 26.235 describes the codecs to be used for video telephony.
The protocols and codecs used for video telephony on the CS domain side and on the IMS side are summarized once again in the following:
CS Network (in Particular 3GPP CS Domain):
Call control:BICC or ISUPNegotiation between pure voice telephony andvideo telephony can be effected by using‘UDI Fallback’ for ISUP and by using‘SCUDIF’ for BICC.MultimediaH.324M (H.324 Annex C):Protocol suite:Codec negotiation:H.245 inband negotiation by way of the set-upCS bearer at 64 kbit/sVideo codec:Support for H.263 prescribedH.261 optionalMP4V-ES (simple video profile level 0) optionalVoice codec:Support for NB-AMR prescribedWB-AMR optionalG.723.1 recommendedTransport:Multiplexing of voice and video on a bearer asdefined by H.223Annex A-BIMS (Codecs for GPRS Access Network):
Call control:SIPContains both negotiation between pure voicetelephony and video telephony, and also codecnegotiation.Codec negotiation:Before setup of the bearer out-of-band byusing SDP, which is transported in SIPVideo codec:Support for H.263 prescribedH.264 optionalMP4V-ES (simple video profile level 0) optionalVoice codec:Support for NB-AMR and WB-AMR prescribedTransport:Two separate RTP bearers for voice and video withthe use of different so-called RTP ‘payload’formats -Voice: Nb-AMR + WB-AMR: IETF RFC 3267Video: H.263: IETF RFC 2429H.264 (AVC): IETF RFC 3984MPEG-4: IETF RFC 3016Synchronization of parallel RTP media streams iseffected by using so-called RTP ‘timestamps’,which are negotiated by the Real Time ControlProtocol (RTCP, see IETF RFC 3550).
Alongside or in place of the codecs specified in this instance, however, other codecs can also be supported by the terminals, in particular if the CS terminals are located in the PSTN or if the IMS terminals are not using GPRS as the access network.
It is desirable to use the same video codec and if possible also the same voice codec on the CS side and in the IMS, in order to avoid a transcoding operation. A transcoding of the video codec in particular, but to a lesser extent also of the voice codec, would require considerable computing power and resources in the IM-MGW. Additionally, the transmission would become delayed and the quality of the image or the voice respectively would become worse. If the required bandwidth for the codecs is different on the CS domain side and the IMS side, additional bandwidth would be used on one side without the image or voice quality improving as a result.
For this purpose, it is a requirement that the MGCF and the IM-MGW exchange suitable information referring to the negotiation of the voice and video codecs by using H.245 and SIP/SDP, and referring to the setup of the transport connection by using H.223.
A method for exchanging suitable information referring to the negotiation of the voice and video codecs by using H.245 and the setup of the transport connection by using H.223 between the MGCF and the IM-MGW forms the subject matter of the method. As a result, a transcoding for video telephony is largely avoided. The MGCF and the IM-MGW connect a CS network, that is to say a PSTN or a 3GPP CS domain, and also an IP network, which uses SIP and SDP for negotiating the codecs, that is to say for example the IMS.